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(54) A method and computer system for client server inter process communication 



(57) The invention relates to a method for client- 
server interprocess communication comprising the 
steps of: 

registering a client application (20) with a first inter 
network service module (22) by entering a client 
port name, a client physical address, and a redun- 



I t lit! 

inter network service module (23) by entering a 
server port name, a server physical acidress and a 
redundant physical address, 

establishing a connection between the client appii- 
( ) idth i ii "by means 

of ihe client physical address and the server phys- 
ical address, 

synchronizing the first and second inter network 
service modules (22,23), 



u v ^n^c - . ^ ht wt 

client application " and the server application 
(21) by means of the redundant client physical ad- 
dress and the redundant server physical address in 
case a predetermined condition is fulfilled. 
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Description 

FieSd of the invention 

[0001] The presenl invention relates to the field of cli- 
ent-server inter process communication, and more par- 
ticularly to client-server inter process communication in 
an industrial automation system. 

Background and prior art 

[0002] Many software applications are based on a 
multi-tier architecture where different components of the 
same application perform a variety of tasks in a distrib- 
uted way. This requires the exchange of commands and 
data between the different components, in such an ar- 
chitecture a client-server connection is established be- 
tween two layers. 

[0003] The distributed component objects model 
(DCOM) is a protocol that enables softw re components 
to communicate directly over a network. Previously 
called "Network OLE", DCOM is designed for use 
across multiple network transports, including Internet 
protocols such as HTTP. DCOM is based on the Open 
Software Foundation's DCE-RPC spec and -works 'with 
both Java applets and ActiveX® components through 
its use of the Component Object Modei(COM). 
[0004] DCOM is an extension of the Component Ob- 
ject Model (COM). COM defines how components and 
their clients interact. This interaction Is defined snob that 
the client and the component can connect without the 
need of any intermediary system component. In today's 
operating systems, processes are shielded from each 

n c c t 1 I 1 ll 1 I 

ponent in another process cannot call the component 
directly, but has to use some form of interprocess com- 
munication provided by the operating system. COM pro- 
vides this communication in a transparent fashion: it in- 
tercepts calls from the client and forwards them to the 
component in another process. When client and com- 
ponent reside on different machines, DCOM replaces 
the local inter process communication with a network 
protocol. 

[0005] Network connections are inherently more frag- 
ile than connections inside a machine. Components in 
a distributed application need to be notified if a client is 
not active anymore, even - or especially - in the case of 
a network or hardware failure. 

[0005] DCOM manages connections to components 
that are dedicated tns s ' < as w as compo 
nents that are 1 1 id i i ^ \; n>, r . \, 
a reference count on each component. When a client 
establishes a connection to a component, DCOM Incre- 
ments the component's reference count. When the cli- 
ent releases its connection, DCOM decrements the 
component's reference count. If the count reaches zero, 
the component can free Itself. 

[0087] DCOM uses a pinging protocol to detect if cli- 



ents are still active. Client machines send a periodic 
message. DCOM considers a connection as broken if 
more than three ping periods pass without the compo- 
nent receiving a ping message, if the connection is bro- 

5 ken, DCOM decrements the reference count and releas- 
es the component if the count has reached zero. From 
the pint of view of the component, both the benign case 
of a client disconnecting and the fatal case of a network 
or client machine crash are handled »y the same refer- 

10 ence counting mechanism. 

[0008] With DCOM, any component can be both a 
provider and a consumer of functionality. The same 
mechanism i "aye communication in 

both directions, making it easy to implement peer-to 

is peer communication, as well as client / server interac- 
tions. 

[0009] it is a major drawback of standard technologies 
like COM or DCOM that they are not designed to satisfy 
the performance and reliability requirements which are 
, =>i in iii'iii.-noi vironments. Such environments 
require very high rates of data exchange with a low net- 

[0010] On the other hand reliability is a key require- 
ment especially for mission critical applications, Aii prior 

or- v\ system t> > v ess con iuni< > >c 

tween two layers relies on standard technologies or pro- 
tocols like COM or DCOM cannot guarantee such a level 
of performance and reliability. 
[001 1] To solve this problem of the prior art two differ- 

30 enf approaches are known: 

us if spe< networking h i 

1 i - i innie; i pro ) 

35 cols which however limit the possibility to freely 
choose networking hardware. 

[0012] All of these approaches are expensive and / or 
1 ( ly y ibl( her ; eriying operating ,,1111 
40 technology evolves. 

[0013] It is therefore an object of the present invention 
to provide an improved method and computer system 
for client server inter process communication as well as 
on a 1 ) fa 0 ] m ln< 

Summary of the invention 

[00M] The underlying problem of the Invention is 
solved basically by applying the features laid down in 

so the independent claims. Preferred embodiments of the 
invention are given In the dependent claims. 
[0015] The present invention Is particularly advanta- 
geous In that it enables to c t - ate 3 di stributed computer 
system featuring the reliability which is required for a 

55 mission critica application such as 1 if Indus nai au 
tarnation environment. In particular this is accomplished 
by providing redundancy support for failures of network 
connections. 
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[0018] in accordance with a preferred embodiment of 
the invention a general software service and library are 
utilized in order to virtuaiize all the operations needed 
by any client-server application to handle the server side 
arid the client side parts. 

[0017] Preferably this service is based on standard 
networking technologies like Windows Sockets, but at 
the same is abie to tightly control the inter process com- 
munication in order to guarantee the best performance 
) ing redundant network- 
ing adapters. 

[0018] In accordance with a further preferred embod- 
iment of the invention Windows Sockets is used to pro- 
vide a sin tU i i j m 
across all TCP / IP protocol stacks for the Implementa- 
tion of the genera! software service and library to virtu- 
alize the required client-server operation. Windows 
sockets is a software tecl k N - o^. 1 .as such known 
from the prior art (cf. "Windows Sockets Network Pro- 
gramming", by Quinn and Dave Shuts, Addison-Wesley, 
Reading,' MA, ISBN: 
0-201-63372-8) 

[0019] in accordance with a further preferred ernbod- 
i e Dfthe »ent e i ir> ies eco exit 
of the inter process communication and provides a gen- 
eral-purpose server-Side and client-side set of functions 
that allow to easily implement client-server applications 
without the burden of handling high-performance and 
reliable communication as well as redundant networks. 
In fact such networking tasks are completely encapsu- 
lated and not visible to the server and client applications. 
[0020] Further the invention enables to dramatically 
simplify the development of client-server applications. 
Networking tasks as synchronisations, data transmis- 
sion and network failure detection are Integrated in the 
software service and library of the invention such that 
the developer of a client-server application is freed from 
such aspects of the system requirements. Further the 
< f nti ill x III Ik nit < s cornn 
cation allows to apply sophisticated policies for perform- 
ance detection and tuning as well as advanced diagnos- 
tics and bug searching. 

[0021] in particular, the automatic management of 
network redundancy allows to configure reliable con- 
nections between computers at very low cost, using nor- 
ma! network adapters and avoiding the purchase of ded- 
icated hardware which simplifies the supplying and 
maintenance procedures. 

[0022] inaccc i nee ith s further preferred embod- 
iment of the invention standard networking protocols 
such as TCP / IP are supported; further the virtualisation 
allows to port the infer process communication (! p C) 
server to other protocols like http, SOAP and others. 
[0023] In accordance with a further aspect of the in- 
vention load balancing is enabled based on redundant 
networks. The load balancing forms part of the software 
service and library in accordance with the present in- 
vention. 
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[0024] Further it is to be noted that the client side and 
the server side can be installed on the same computer 
for local communications applications or on different 
computers for remote communications applications. 
5 The different computers can be connected by means of 
a local area network (LAN) or by means of a wide area 
network (WAN). 

Brief description of the drawings 

[0025] in the following a preferred embodiment of the 
invention is des i i j ,e- detail by making refer- 
ence to the drawings in which: 

15 Figure 1 is t - t- - - n en 
vention in a LAN, 

Figure 2 is illustrative of the inter process communi- 
cation data flow, 

20 

Figure 3 is illustrative of an application of the inven- 
tion involving interne! communication. 

[0026] Figure 1 shows a computer system comprising 
?5 workstations 10, 11, 12 and 1 Ea t t 

10. 11 and Id li i • 3 i whereas work- 
station 13 has a server application. The workstations 10, 

11. 12 and 13 are connected by a network 14. Optionally 
the workstations 10, 11, 12 and 13 are connected by a 

30 redundant network 15. 

[0027] Figure 2 illustrates the inter process communi- 
cation data flow. The inter process communication data 
flow involves a client application 20 and a server appli- 
cation 21. The cHem application and the server appiica- 

35 tjon have dedicated inter network service modules 22 
and 23, respectively. 

[0028] Both of the inter network service modules 22 
2 ea vii m a dI ySica 

connection table 25. 
<o [0029] For example, when the client application 20 is 
initialised it is registered in its dedicated inter network 
service module 22 by creating entries m the virtual con- 
nection table 24 and the physical connection table 25. 
[0030] The virtual connection table 24 serves to store 
« the client port -ar in other words the client port It 
whereas the physical connection table 25 serves to 
store the physical address of the corresponding connec- 
tion path. When redundant network connections are 
available (cf. network 15 of figure 1) the redundant net- 
so work connection Is also entered into the virtual connec- 
tion table 24 and the physical connection table 25 by 
specifying one or ire e aits < lames and one 
or more alternative physical addresses. 
[0031] The same applies r - yforregister- 

55 ing the server application 21 with its dedicated internet- 
work service module 23. it is important to note that the 
virtual connection tables 24 and the physical connection 
tables 25 of the inter network service modules 22 and 
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23 are copies of each other which is accomplished by 
synchronising the contents of these tables, 

[0032] Further both of the inter network service mod- 
ules 22 and 23 have a socket port 26 for sending and 
receiving of data via a network connection (cf. network 
14 and network 15 of figure 1). 
[0033] When the client application sends the request, 
such as; a question 27. a corresponding function of the 
API is invoked in orde' to input Ih; ques on 27 iio e 
input queue 28 of the inter network service module 22. 
When the question 27 is processed a connection path 
is determined by accessing the virtual connection table 

24 and the physical connection table 25 of the inter net- 
work service module 22. 

[0034] his way the ques 27 - ipJ m 
data packet whir listobt isi < >the appropriate 
server application 21. This transformation of the re- 
quests of the input queue 28 results in an unnamed out- 
put queue 29. This output queue 29 is processed by the 
socket port 26 and outputted over the appropriate net- 
work connections. 

[0035] The question 27 is send from the socket port 
26 to the inter network service module 23 of the server 
application 21 . By means of the virtual connection table 
24 and the physical connection table 25 of the inter net- 
work service module 23 the puor transformation of the 
question 27 by means of the virtual connection table 24 
and the physical connection table 25 of the inter network 
service module 22 is inverted. This way the question 27 
is received and inputted to the server application 21 by 
means of input queue 30. 

[0036] After processing of the question 27 by the serv- 
er application 21 the corresponding answer 31 is send 
back to the client application 20. The procedure for 
e answer 31 back to the client application 20 
s to the communication path form the client 
application 20 to the server application 21. As a conse- 
quence an input queue 28 and an output queue 29 is 
created in the Inter network service module 23 corre- 
sponding to the input queue 28 and the output queue 
29 of the Inter network service module 22. 
[0037] This data flow enables the following architec- 
tures: 

Server-side architecture 

1. Declare a "port" identified by an alphanumeric 
siring. 

2. Wait f e clieni side 
(local or remote). 

3. Read the message received. 

4. Prepare the corresponding "response message" 



and send it to the 
5. Go to step 2. 



server aop ; ) re- 

sponse In order to avoid the queuing of Incoming mes- 
sages. However by means of little more programming 
code it is possible to implement a server application with 
"parallel" architecture in order to avoid queuing prob- 
lems, like in the following embodiment: 

1. Declare a "port" identified by an alphanumeric 
siring. 

2, Wait for messages coming from the client side 
(local or remote). 



d (he rr 



sage. 



[0038] The server application can create multiple 
ports. In this case it is necessary to Instantiate a different 
wailing loop for each port. 

[0039] A disadvantage of this approach is that the 



4. Detach a thread in order to prepare the corre- 
sponding "response message". 

5. Send an "acknowledge" message to the client in 
order to notify that the message has been correctly 
received. 

6. Go to step2. 

x 1 i f hp In < v pn i <■ 

response, send it to the corresponding client, then 
terminates itself. 

Client-side architecture 



1 . Open a connection with the server application (lo- 
cal or rem > e i .it name declared by 
the server itself. 

2. Send a message and wait for the response mes- 
sage. 

3. Read the response message. 

4. Go to step 2. 

[0041] This makes it possible to send messages that 
do not require a response, i.e. a datagram or similar 
messages. !t is also possible to open multiple connec- 
tions with the same server or with different servers. 
However, with this architecture it is not possible to send 
a message while on the same connection there is a 
thread waiting for a response. This possibility is provid- 
ed by the following approach: 

1. Otter; a connection with the server side (local or 
remote). 

2. Specify a callback function to be called when a 
"response" message is received. 

3. Senci a message without waiting for response 
(waiting timeout=0). 

4. Go to step 3. 

[0042] When a new ge is received 

by the inter network service module, the callback func- 
tion will be called so the client application will receive 
the response message and a reference identifier to the 
associated sent message. 

[0043] This type of architecture is useful, for instance, 
for a server application developed in parallel architec- 
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lure thai car! receive from the same client different types 
of "question messages" implying very different answer 
preparing times, in these cases the client application 
can send the "question" from a thread and await the "an- 
swer" from the callback so the "answer" to "simple ques- 
tions" will be received in a short time, while the "answer" 
to "complex questions" will arrive later A client applica- 
tion can open multiple connections to the same server 
or to different servers. 

[0044] it is important to note that the inter network 
service modules 22 and 23 manage redundant networks 
in a way which it to the client 

and serve:' applications. 

[0045] For example, it is possible to connect the serv- 
er and client computers using two common network 
adapter cards. Different kinds of networks can be uti- 
lized; for instance one network can be the Ethernet and 
the other network can be a token ring network. 
[0046] a 
server application, the connection Is established on one 
of the two networks. If the network selected fails over, 
the communications automatically switches to the other 
one but neither the client and server application detect 
the event and both will continue the norma! communi- 
cation activity. 

[0047] it is possible to configure the priority network, 
i.e. the first network on which to retry the connection op- 
erations. If for any reason that network is not available, 
automatically the connection will be established on the 
other network. 

[0048] The automatic switch can happened also if the 
network in use is too slow, in this case an adaptive al- 
gorithm modifies the timeouts used for detection of net- 
work failure in order to avoid subsequent unnecessary 
switches. This type of management permits to apply an 
automatic "load balancing" policy. 
[0049] II is a further advantage thai the inter network 
service modules on each computer only use one port 
number in order to communicate with the other inter net- 
work service modules, Independently from the number 
of applications which are connected. This simplifies the 
nanagemento 5i , v 1 
used architecture. The port number can be configured. 
[0050] Further this inter process communication serv- 
ice allows to monitor and to test the communication ac- 
tivity in order io make performance iesis or 1o solve com- 
munication problems which are caused by the server or 
client applications. The monitoring can be managed lo- 
cally or remotely on each computer included in a list that 
defines a logical network. 

[0051] Further a remote queue service can be imple- 
mented by means of the inter process communication 
sen/ice of the invention. An application can create a 
i qiie e an be queued 

om anoih v ion mini so on a ciltferen 
computer, it is possible to have many applications dis- 
tributed on the network queuing data on the same 
queue. The queue is dynamically expanded when nec- 



' md th€ < e no constraints al wt the dimension 
of each element. This type of remote queue is volatile, 
i.e. not perm; i 6 nented. 

[0052] Figure 3 - 
5 workstations 35, 36, 37, 38 and 39 which are coupled 
by means of a network 40. T he workstations 35, 36 and 
37 run client applications whereas the workstation 38 
has a server application. 

[0053] The workstation 39 serves to provide inter 
io process communication through internet 41 . This :s im- 
plemented by means of a service extension which is in- 
stalled on the web-server workstation 39. For this pur- 
pose an ISAPi extension in IIS can be utilized. In this 
case the HS installs several ISAPI extensions which 
is are .dlls that provide exten - a y he ISAPi 

extensions can be implemented as ISAPI tillers to inter- 
cept incoming htip requests. 

[0054] Further the system comprises workstations 43, 
44 and 45 which are coupled by a network 46. 

i'O [0055] The workstations 42, 43 and 44 have client ap- 
plications which are devek ped as OCX 1 
a web client. The inter process communication service 
of the invention is loaded by a browser program of the 
corresponding workstation 42, 43 or 44 as a DLL. This 
way it Is possible io connect the client application to a 

n ,< ru rwork m co 

ed to a web server - for example Microsoft MS. 
[0056] The inter process communication service ex- 
tension for the web is installed on the web server on 

30 workstation 39 - for example using ISAPI extensions in 
IIS. 

[0057] The client applications running on the worksta- 
tion 42, 43 and 44 are connected to the server applica- 
tion on workstation 38 through proxy server 45. 



Claims 

1. A method for client-server Inter process communi- 
cation comprising the steps of: 

idin lien > j i i 1 I erver 
application (21) 

providing at least a first and a second network 
(14, 15) for coupling the client application and 
the server application, 

providing a first inter network service module 
(22) for the client application and a secor ■■ i inter 
network service module (23) for the server ap- 
plication, 

registering (24, 25) the client appiica' 
the first inter network service module by enter- 
ing a client port name and a client physical ad- 
dress, 
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registering (24, 25) the server application with 
the second inter network service module by en- 
tering a server port name and a server physical 

address, 

entering at least one redundant client physical 
ressin ti id; network service module 
and one redundant server physical address the 
second inter network service module, 

establishing a connection between ihe client 
application and the server application by- 
means of the client physical address and the 
server physical address, 

synchronizing the firs! and second inter net- 
work service modules, 



establishing a redundant connection between 
ihe client application and the server application ?o 
by means of the redundant client physical ad- 
dress and the redundant server physical ad- 
dress in case a predetermined condition is ful- 
filled. 

25 

2. The method of claim 1 , the predetermined condition 
being a failure of ihe connection between the client 
physical address and the server physical address. 

3. The method of claim 1 or 2, ihe condition being a 30 
predetermined response time which is exceeded. 

4. The method of claims 1 , 2 or 3 whereby only one 
socket port (26) is used for the client port and the 
server port, respectively. 35 

5. The method of anyone of the preceding claims 1 to 

4, whereby a client virtual connection table (24) and 
a < f M v al • ^ S m > 
storage of the client port-name and the client phys- *> 
ical address, respectively, and whereby a server vir- 
tual connection table (24) and a server physical 
connection table (25) are used for storing of ihe 
server port-name and the server physical address, 
respectively. *> 

6. The method of anyone of the preceding claims 1 to 

5, whereby a client input queue (28) is formed in the 
first inter network service module, ihe client input 
queue compn , he client application, so 
the client input queue be i to an out- 
put queue (29) for outputting via the single client 
socket port. 

7. The method of anyone of the preceding claims 1 to 55 

6, whereby the first network is an Ethernet type net- 
work and ihe second network is a token ring type 

network. 



8. The method of anyone of the preceding claims 1 to 
7, wheren / i at on 3nd ihe server ap- 
plication belong to an industrial automation system. 

9. A computer program product for performing a meth- 
od In accordance with anyone of preceding claims 
1 to 8. 

10. A computer system, such it an ' -.t- a a t"i ' 

system, cot ; i is >eriomnr;g a 
method m accordance with anyone oftne preceding 
claims 1 to 8. 
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